從想法到程式碼：Specification-Driven Development 完全實戰指南

在現代軟體開發中，需求文件與最終實作成品之間的鴻溝，往往是導致專案延遲、重工甚至失敗的主因。傳統流程將規格文件視為開發前的參考，一旦開發啟動，文件便迅速過時。為了解決這個痛點，一種名為「規格驅動開發」（Specification-Driven Development, SDD）的新方法論應運而生，它徹底顛覆了開發流程，將「規格」從輔助文件提升為可直接生成程式碼的核心。

本文將帶你深入了解 SDD 的核心理念，並透過一個待辦事項（To-Do List）應用的實例，一步步教你如何使用 spec-kit 與 GitHub Copilot 等 AI 工具，實踐這套先進的開發方法。

SDD 的核心理念：規格即是真相

Specification-Driven Development 的核心思想是將規格（Specification）視為系統唯一的「真相來源」（Source of Truth）。這代表著幾個關鍵的轉變：

1. 規格即程式碼 (Spec is Code)：程式碼的存在是為了服務規格，而非規格服務程式碼。規格本身必須足夠精確、清晰，以至於可以直接轉譯或生成可運作的系統。
2. 消除轉譯落差 (Eliminate Translation Gaps)：傳統開發中，產品經理的需求、開發者的理解、最終的程式碼之間存在多次「轉譯」，每次轉譯都可能產生資訊落差。SDD 透過讓規格直接生成程式碼，消除了這個問題。
3. 系統化變更管理 (Systematic Change Management)：當需求變更時，我們不再是直接修改程式碼，而是回到規格層面進行修改，再重新生成對應的程式碼。這確保了程式碼與文件永遠保持同步。

實戰流程：6 步驟打造你的第一個 SDD 專案

接下來，我們將以建立一個「待辦清單管理系統」為例，展示 SDD 的完整流程。

準備工作

• 開發環境：Visual Studio Code
• AI 助手：GitHub Copilot (本文示例基於 GPT-5 模型)
• 終端機：PowerShell (Windows)

步驟 1：安裝 spec-kit 並初始化專案

spec-kit 是由 GitHub 推出的實驗性工具集，旨在輔助實踐 SDD。由於它仍在快速迭代中，請以官方最新文件為準。

首先，打開你的 PowerShell 終端機，執行以下指令來初始化一個名為 todo.list 的專案：

uvx --from git+https://github.com/github/spec-kit.git specify init todo.list

執行完畢後，你會在專案資料夾中看到由 spec-kit 自動產生的幾個核心目錄，包含 Prompt、Script 與 Template，這些是後續與 AI 互動的基礎設定。

步驟 2：定義開發憲章 (/constitution)

「憲章」（Constitution）是整個專案的最高指導原則。它定義了程式碼產生的風格、品質標準、測試要求與效能基準。一份好的憲章是確保 AI 生成高品質、一致性程式碼的關鍵。

在 VS Code 中，透過 GitHub Copilot Chat，下達你的第一個指令：

/constitution

接著，定義你的專案法規。例如：

「建立專案開發憲章，包含以下原則：

1. 程式碼品質：遵循 C# SOLID 原則，程式碼需包含完整的 XML 註解。
2. 測試標準：所有公開方法都必須有對應的單元測試，測試覆蓋率不得低於 85%。
3. 效能需求：應用程式啟動時間應少於 2 秒，資料庫查詢回應時間應在 100ms 以內。」

AI 會根據你的描述，生成一份詳細的憲章文件，作為後續所有步驟的參考基準。

步驟 3：撰寫功能規格 (/specify)

這個階段，你需要扮演產品負責人（Product Owner）的角色，專注於定義「為什麼要做」和「需要做什麼」，完全避免陷入「如何實現」的技術細節。

繼續在 Copilot Chat 中下達指令：

`/specify 建立一個待辦清單管理系統，使用者需要能夠：

1. 新增待辦事項，包含標題與支援 Markdown 格式的內容。
2. 設定每個事項的提醒時間。
3. 將事項標記為已完成。`

Copilot 會基於此需求，建立一個新的功能分支，並產生一份名為 spec.md 的規格文件。這份文件通常會包含：

• Scenario：主要使用情境。
• Edge Case：需要考慮的邊界案例。
• Functional Requirement：明確的功能性需求條列。
• Non-functional Requirement：非功能性需求（如效能、安全性）。

你會發現文件中有些地方被標記為 [NEEDS CLARIFICATION]。這是 AI 認為規格不夠明確的地方，你需要逐一回答這些問題，直到規格完整、無歧義為止。若涉及使用者介面（UI），建議在此階段補充介面佈局（Layout）與使用者體驗（UX）的行為描述。

步驟 4：擬定技術實作計畫 (/plan)

當規格明確後，就進入了技術規劃階段。在這裡，我們將決定「用什麼技術」以及「怎麼做」。

下達 /plan 指令，並指定你的技術棧：

/plan 採用 C# 語言，搭配 Avalonia UI 框架與 LiteDB 作為本機資料庫。

AI 會根據這份技術選型和先前的 spec.md，產出一份完整的技術計畫，內容可能包含：

• 系統架構圖
• 專案資料夾結構
• 資料庫 Schema 設計
• 開發方法與模式（如 MVVM）
• 任務拆分建議
• 對照憲章的技術決策評估

這份計畫產出後，需要由開發團隊進行審核，確保其符合團隊的技術標準與公司的內部規章。

步驟 5：任務分解 (/tasks)

規格與計畫都已確認，接下來就是將宏大的計畫分解為可執行的小任務。

直接下達指令：

/tasks

Copilot 會讀取 spec.md 和技術計畫，自動產生一份詳細的任務清單。每個任務都會清楚說明需要實作的具體內容，甚至建議需要建立的類別（Class）名稱與方法（Method）簽名。

步驟 6：執行開發任務 (/implement)

這是最後的程式碼實現階段。你可以根據 /tasks 產生的清單，一步步地進行開發。

使用 /implement 指令來處理單一任務：

/implement 執行任務 #1：建立 TodoItem Model 與資料庫存取邏輯。

AI 將會根據任務描述，直接生成對應的 C# 程式碼。你也可以將所有任務推送到 GitHub Issues，指派給團隊成員或其他的 Coding Agent 協同開發，大幅加速專案進度。

SDD 的實務價值與適用情境

導入 SDD 不僅僅是改變工具，更是開發思維的轉變。它帶來了顯著的價值：

• 規格與程式碼永遠同步：軟體的維護等同於規格的演進，從根本上解決了文件過時的問題。
• 快速驗證與重構：從一個模糊的想法到一份完整的技術規格，最快可在 60 分鐘內完成。這讓團隊能快速進行技術探索與平行開發。
• 團隊知識的沉澱與傳承：所有的設計決策、架構考量與需求理由都被完整記錄在規格與計畫中，可供追溯，新成員也能快速上手。

SDD 特別適用於以下情境的團隊：

• 需求變更頻繁，需要快速回應市場的專案。
• 高度重視文件品質與可維護性的團隊。
• 希望減少需求與實作之間資訊落差的開發環境。

最新進展

spec-kit 仍在不斷進化，近期新增的 /clarify 與 /analyze 指令，能幫助開發者更快地釐清規格中的模糊地帶，並分析目前規格的覆蓋率，讓整個流程更加完善。

Specification-Driven Development 正引領我們進入一個全新的開發範式，一個由 AI 深度參與、讓開發者能更專注於創造性工作的時代。